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Telephony Routing over IP (TRIP) Attribute for Resource Priority 
Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 
improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Abstract 


This document defines a new attribute for the Telephony Routing over 
IP (TRIP) protocol. The attribute associates protocols/services in 
the PSTN offering authorized prioritization during call setup that 
are reachable through a TRIP gateway. Current examples of 
preferential service in the Public Switched Telephone Network (PSTN) 
are Government Emergency Telecommunications Service (GETS) in the 
U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. 
The proposed attribute for TRIP is based on the NameSpace.Value tuple 
defined for the SIP Resource-Priority field. 


1. Introduction 


An IP telephony gateway allows nodes on an IP-based network to 
communicate with other entities on the circuit switched telephone 
network. The Telephony Routing over IP (TRIP) protocol [rfc3219] 
provides a way for nodes on the IP network to locate a suitable 
gateway through the use of Location Servers. TRIP is a policy- 
driven, inter-administrative domain protocol for advertising the 
reachability, negotiating the capabilities, and specifying the 
attributes of these gateways. 


The TRIP protocol is modeled after BGP-4 [rfc4271] and uses path- 
vector advertisements distributed in a hop-by-hop manner (resembling 
a Bellman-Ford routing algorithm) via Location Servers. These 
Location Servers are grouped in administrative clusters known as 
Internet Telephony Administrative Domains (ITADs). A more extensive 
framework discussion on TRIP can be found in [rfc2871]. 
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This document defines a new attribute that has been registered with 
IANA. The purpose of this new attribute, and the rationale behind 
its specification, is explained in the following sections. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [rfc2119]. 


2. Emergency Telecommunications Service 


Emergency Telecommunications Service is a broad term that refers to 
the services provided by systems used to support emergency 
communications. One example of these systems is the U.S. Government 
Emergency Telecommunications Service (GETS). This system currently 
operates over the U.S. Public Switched Telephone Network (PSTN) as a 
pay-per-use system by authorized personnel. It uses the T1.631-1993 
ANSI standard [ANSI] to signal the presence of the National Security 
/ Emergency Preparedness (NS/EP) codepoint in an ISDN User Part 
(ISUP) Initial Address Message (IAM) for Signaling System No. 7 
(SS7). A key aspect of GETS is that a signaling standard in the U.S. 
PSTN is used to convey the activation/request of the GETS service. 


From a protocol perspective, other examples of priority (and which 
can be argued as emergency/disaster related) standards are the 
H.460.4 ITU [itu460] standard on Call Priority designation for H.323 
calls, and the 1.255.3 [itu255] ITU standard on Multi-Level 
Precedence and Preemption Service. The latter has been integrated 
into private telephony systems like AUTOVON. In both cases, 
signaling codepoints exist to distinguish telephony calls by 
authenticated and prioritized end-user from the normal end-user. The 
form of this distinction varies and is outside the scope of this 
document. [rfc3689] and [rfc3690] provide additional information on 
ETS and its requirements. 


3. SIP Resource-Priority Effort 


The initial discussions in the IEPREP working group list, along with 
the presentation at the Adelaide IETF [ADELO0], led to strawman 
requirements to augment SIP to have the ability to prioritize call 
signaling. This effort was then advanced formally in the SIPPING 
working group so that SIP would be able to prioritize access to 
circuit-—switched networks, end systems, and proxy resources for 
emergency preparedness communication [rfc3487]. 


The requirements in [rfc3487] produced the corresponding document 


[rfc4412] in the SIP working group, which defines a new header for 
SIP called Resource-Priority. This new header, which is optional, is 
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divided into two parts: a NameSpace and a Value. The NameSpace part 
uniquely identifies a group of one or more priorities. The Value 
part identifies one of a set of priorities used for a SIP message. 


3.1. Benefits 


There are three basic benefits derived from the addition of the 
Resource Priority header in SIP. The first is an ability to signal 
the priority within a SIP message to other entities in an IP network. 
The caveat is that some entities may not recognize/support the 
priority or namespace, but at least the ability to signal the 
priority with respect to resources has been specified in the SIP 
protocol. 


The second benefit is that telephony-related protocol/codepoints from 
other standards can have a corresponding mapping to SIP NameSpace and 
Value tokens in the Resource-Priority header. Hence, the current 
NS/EP codepoint in ANSI standard T1.631-1993 could have a 
corresponding NameSpace.Value token set for the IETF standards body. 
And as a result, this mapping would facilitate the transparent 
bridging of signals (i.e., codepoints) between standards defined by 
various organizations -- be they private or public. 


The third benefit of the Resource-Priority header, and its definition 
of alphanumeric tokens, is that it is highly versatile. The 
NameSpace allows for a wide set of priorities to be defined and 
updated, if the need arises, by simply defining a new NameSpace 
token. Hence, there is no reliance on a single set of priorities 
applied for all cases. 


3.2 Issue 


Having defined a means of signaling priority through gateways, the 
follow-on question arises of how does one determine which gateways 
support a given NameSpace. The dissemination of this type of 
information is within the scope of TRIP. However, the current 
specification of TRIP does not include a component that advertises 
associations of gateways with specific NameSpaces. To address this 
omission, the following section defines a new TRIP attribute that 
associates one or more NameSpaces with a gateway. 
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4. 


4. 


New Attribute: ResourcePriority 


This section provides details on the syntax and semantics of the 
ResourcePriority TRIP attribute. Its presentation reflects the form 
of existing attributes presented in Section 5 of [rfc3219]. 


Attribute Flags are set to the following: 


Conditional Mandatory: False 

Required Flags: Not Well-Known, Independent Transitive 
Potential Flags: None 

TRIP Type Code: 12 


There are no dependencies on other attributes, thus Conditional 
Mandatory is set to "False". 


Since the Resource-Priority field in SIP, with its corresponding 
NameSpace token, is optional, the ResourcePriority attribute in TRIP 
is also optional. Hence, it is set to "Not Well-Known". 


The Independent Transitive condition indicates that the attribute is 
to be forwarded amongst all ITADs. The Location Server that does not 
recognize the attribute sets the Partial flag as well. 


1. Syntax of ResourcePriority 


The ResourcePriority attribute contains one or more NameSpace token 
identifiers. An initial set of identifiers is defined in [rfc4412], 
with subsequent identifiers to be found in the IANA registry. The 
syntax of the ResourcePriority attribute is copied from the 
"namespace" token syntax from [rfc4412], which in turn imported 
"alphanum" from [rfc3261], and is an alphanumeric value as shown 
below: 


namespace = 1* ( alphanum / wow / wom / wow fs wee / nes / wan 


/ wv / wrew / new ) 


Note that an augmented version of Backus-Naur Form is found in 
[rfc4234]. 


Since NameSpaces are arbitrary in length, each tuple consists of a 
Length value with a NameSpace value as shown in the figure below. 
There is no padding between tuples. 


Carlberg & O’Hanlon Standards Track [Page 4] 


RFC 5115 Resource Priority Attribute January 2008 


0 dL. 2 3 
01234567890123456789012345678<901 
+--------------- +--------------- +-------------- +---------------- + 
| NameSpace Length | NameSpace Value (variable) | 
+--------------- +--------------- +-------------- +---------------- + 


It is important to note that the priority (i.e., "r-priority" token 
syntax) from [rfc4412] is NOT used in the ResourcePriority attribute. 
This is because the objective of the attribute is to advertise the 
NameSpace associated with a gateway and not the individual priorities 
within that NameSpace. 


4.2 Additional TRIP Considerations 


Section 5.12 of TRIP lists a number of considerations that should be 
addressed when defining new attributes. The first three 
considerations (use of the attribute, its flags, and syntax) have 
been discussed above in this section. The final three considerations 
are the following. 


4.2.1. Route Origination 
The ResourcePriority attribute is not well-known. If a route has a 
ResourcePriority attribute associated with it, the Location Server 
(LS) MUST include that attribute in the advertisement it originates. 
4.2.2. Route Aggregation 
Routes with differing ResourcePriority token values MUST NOT be 
aggregated. Routes with the same token values in the 
ResourcePriority attribute MAY be aggregated and the same 


ResourcePriority attribute attached to the aggregated object. 


4.2.3. Route Dissemination and Attribute Scope 


An LS MUST include the ResourcePriority attribute when communicating 
with peer LSs within its own domain. 


If received from a peer LS in another domain, an LS MUST propagate 
the ResourcePriority attribute to other LSs within its domain. 


An LS MAY add the ResourcePriority attribute when propagating routing 
objects to an LS in another domain. The inclusion of the 
ResourcePriority attribute is a matter of local administrative 
policy. 
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5. Security Considerations 


The document defines a new attribute for the TRIP protocol and has no 
direct security considerations applied to it. However, the security 
considerations for TRIP and its messages remain the same and are 
articulated in Section 14 of [rfc3219]. 


6. IANA Considerations 


As described in Section 4 above, one new "TRIP attribute" has been 


defined. Its name and code value are the following: 
Code Attribute Name 
12 ResourcePriority 


These assignments are recorded in the following registry: 
http://www.iana.org/assignments/trip-parameters 
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